Cable modems/emtas under test

ABSTRACT

A system for testing multiple cable modem/eMTA devices independently and simultaneously using different types of device probes is disclosed. The system includes real-time, bi-directional/asynchronous communication and interaction between the system components.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. Patent Application entitledCABLE MODEMS/EMTAS UNDER TEST, Ser. No. 14/948,143, filed Nov. 20, 2015,which is hereby incorporated by reference in its entirety.

This application is related to U.S. Patent Application entitled CORETESTING MACHINE, Ser. No. 14/866,720, filed Sep. 25, 2015; U.S. PatentApplication entitled UNIVERSAL DEVICE TESTING INTERFACE, Ser. No.14/866,752, filed Sep. 25, 2015; U.S. Patent Application entitledUNIVERSAL DEVICE TESTING SYSTEM, Ser. No. 14/866,630, filed Sep. 25,2015; U.S. Patent Application entitled SET TOP BOXES UNDER TEST, Ser.No. 14/866,780, filed Sep. 25, 2015; U.S. Patent Application entitledWIRELESS ROUTERS UNDER TEST, Ser. No. 14/948,925, filed Nov. 23, 2015;U.S. Patent Application entitled HARDWARE ARCHITECTURE FOR UNIVERSALTESTING SYSTEM: CABLE MODEM TEST, Ser. No. 14/929,180, filed Oct. 30,2015; U.S. Patent Application entitled: HARDWARE ARCHITECTURE FORUNIVERSAL TESTING SYSTEM: WIRELESS ROUTER TEST, Ser. No. 14/929,220,filed Oct. 30, 2015; and U.S. Patent Application entitled TEST SEQUENCESUSING UNIVERSAL TESTING SYSTEM, Ser. No. 14/987,538, filed Jan. 4, 2016,each of which are hereby incorporated by reference in its entirety.

TECHNICAL FIELD

The present invention is directed to a system for testing devices.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the aforementioned aspects of theinvention as well as additional aspects and embodiments thereof,reference should be made to the Description of Embodiments below, inconjunction with the following drawings in which like reference numeralsrefer to corresponding parts throughout the figures.

FIG. 1 illustrates a high-level system architecture for testing devices,according to certain embodiments.

FIG. 2 illustrates some of the testing components and the interactionbetween the testing components, according to certain embodiments.

FIG. 3 illustrates a sample architecture that includes the testingcomponents, according to certain embodiments.

FIG. 4 illustrates a cable modem/eMTA device under test, according tocertain embodiments.

DETAILED DESCRIPTION

Methods, systems, user interfaces, and other aspects of the inventionare described. Reference will be made to certain embodiments of theinvention, examples of which are illustrated in the accompanyingdrawings. While the invention will be described in conjunction with theembodiments, it will be understood that it is not intended to limit theinvention to these particular embodiments alone. On the contrary, theinvention is intended to cover alternatives, modifications andequivalents that are within the spirit and scope of the invention. Thespecification and drawings are, accordingly, to be regarded in anillustrative rather than a restrictive sense.

Moreover, in the following description, numerous specific details areset forth to provide a thorough understanding of the present invention.However, it will be apparent to one of ordinary skill in the art thatthe invention may be practiced without these particular details. Inother instances, methods, procedures, components, and networks that arewell known to those of ordinary skill in the art are not described indetail to avoid obscuring aspects of the present invention.

According to certain embodiments, an innovative system can test a set ofdevices simultaneously. Further, such a testing system is capable oftesting disparate devices simultaneously.

According to certain embodiments, such a testing system provides aseparate set of interfaces for each device that is under testing of theset of devices. Further, such a system is designed to be adaptive bybeing extendable for testing new devices with corresponding new testinginterfaces without fundamentally changing the core architecture of thetesting system. As a non-limiting example, the testing system includes acore testing subsystem with a user interface and asynchronouscommunication among the system components such that new types of devicesand new tests can be added and executed in a seamless fashion.

According to certain embodiments, the user interface can communicatethrough web sockets with the universal tester. Such communication is inreal-time, bi-directional and asynchronous so that the user can controland monitor the testing of multiple devices simultaneously andindependently of each other using the same universal tester and itsassociated test bench.

According to certain embodiments, the testing system is capable oftesting a set of similar types of devices or a set of disparate devices.

According to certain embodiments, a testing solution system can be athree layer implementation. The number of layers may vary fromimplementation to implementation. FIG. 1 illustrates a high-level systemarchitecture for testing devices, according to certain embodiments. FIG.1 shows a test bench browser interface 102 that is in communication witha web-socket 104, that is, in turn, in communication with a core testingprocessor 106. According to certain embodiments, the communicationbetween the test bench browser 102, web-socket 104 and core testingprocessor 106 can be a TCP/IP communication. As a non-limiting example,the web browser is used as a user interface that communicates throughweb-sockets with the core testing processor. As a non-limiting example,communication may be in the form of JSON messages using TCP/IP protocol,according to certain embodiments. JSON is Java script object notationfor transmitting data between the server and web applications.

FIG. 2 illustrates some of the testing components and the interactionbetween the testing components, according to certain embodiments. FIG. 2shows a user interface 202, web-sockets 204, a core testing processor206, database 208, test configuration modules 210, testing environmentmodules 212, a plurality of probes (214, 216, 218) to connect thedevices under test (DUT) to the core testing processor 206, and a speedtest module 220, according to certain embodiments. Speed testing is usedfor evaluating the performance of the Wifi and other media networkconnection and accessibility of the device under test. FIG. 2 shows asnon-limiting examples, a Wifi probe 214, an Ethernet local area network(LAN) probe 216 and a MOCA probe 218. In other words, according tocertain embodiments, various probes can be included such as a wirelesslocal area network (WLAN) probe, an Ethernet wide area network (WAN)probe, a multimedia over coax alliance (MoCA) WAN probe, a MoCA LANprobe and a wireless probe via antenna. According to certainembodiments, servers and other components in the testing system may bedistributed over a plurality of computers.

According to certain embodiments, core testing processor 206 loads andreads files from test configuration modules 210 and test environmentmodules 212 to initialize various components of the testing system. Whenthe system is ready to begin testing after the initialization process,the system notifies a user that is using the testing system to test oneor more devices (DUTs) of the readiness of the testing system. . Theuser installs each device or DUT (of the set of DUTs that are to betested) in a separate Faraday cage (slot) in the test bench and theserial number of each DUT is scanned. According to certain embodiments,there are several Faraday cages (slots) in a given test bench so that aplurality of DUTs can be tested simultaneously using the same test benchand same universal tester. The core testing processor 206 receives theserial number information of each DUT and using the serial number,retrieves further information associated with each DUT based on theserial number from database 208, according to certain embodiments. Thecore testing processor 206 dynamically loads test configurationinformation 210 and test environment information 212 based on deviceinformation such as make, model etc of a given DUT. After the testconfiguration and test environment information are loaded, the coretesting processor 206 begins executing the various tests correspondingto each DUT so that the set of DUTs can be tested simultaneously. Eachtest may correspond to underlying testing modules associated with Wifi,LAN, WAN or MoCA etc, interfaces of the DUT and such modules can beexecuted locally, remotely or at the device.

According to certain embodiments, the test configuration informationidentifies the test modules and corresponding testing scripts that areto be executed by the core testing processor 206 at run time. The coretesting processor 206 also provides the test results and other feedbackinformation to the user via the browser user interface 202 and websockets 204. Further, the user can send user input and requests to thesystem through the browser user interface 202 and web sockets 204.

According to certain embodiments, core testing processor 206 determinesthe success or failure of a given test based on the test configurationparameters and output results of the testing. Further, upon failure of agiven test, core testing processor 206 may continue further testing orhalt test execution based on test configuration parameters, according tocertain embodiments.

Upon completion of the relevant tests, a success message can be sent tothe user via the browser user interface 202 and web sockets 204. Eventhough the DUTs in the set of DUTs are tested simultaneously, the userdoes not have to wait until all the testing of the DUTs in the set havebeen completed to begin installing other devices that need testing.Further, the testing of the devices need not be started at the sametime. Soon after the testing is completed for a given DUT, the testedDUT may be uninstalled from its slot (Faraday cage) in the test benchand a new DUT can be installed in its slot so that testing can begin forthe newly installed device.

According to certain embodiments, the test results can be stored locallyand/or pushed to the cloud so that the results can be viewed remotelyfrom any location. Further, the test results can be aggregated.According to certain embodiments, aggregated data includes data combinedfrom several data measurements. Summary reports can be generated fromsuch aggregated data. Non-limiting examples of summary reports includecharts and graphs that display information on all the DUTs or at least asubset of the DUTs. Thus, the summary reports generated from theaggregated data can provide an overview of the testing information andcharacteristics of the DUTs. The aggregated data can reveal trends andother related information associated with the DUTs. Further, theaggregated data can include user-level data, access account activity,etc. According to certain embodiments, the testing system includes abilling system to charge for the testing services for each device.

FIG. 3 illustrates a sample architecture that includes the testingcomponents of a universal tester, according to certain embodiments. FIG.3 shows a browser user interface or operator dashboard 302, a testcontroller 304, a universal tester 306 and a device under test (DUT)308. There may be multiple devices under testing simultaneously but onlyone device under test is shown for convenience in FIG. 3.

According to certain embodiments, browser user interface or operatordashboard 302 may include information 310 associated with each deviceunder test. The information 310 can include DUT serial number 311, andtesting progress information 312. Browser user interface or operatordashboard 302 may also include user command function buttons 314 anddrop down menus (not shown in FIG. 3). According to certain embodiments,the user can configure slot details (e.g., port numbers, IP address forthe slot, etc), configure testing preferences such as push to cloud,export to billing, etc.

According to certain embodiments, test controller 304 may include auniversal tester webserver 316 that is in communication (e.g., TCP/IP)with a universal tester database 318. A billing process within thecontroller (not shown in FIG. 3) may be in communication with a billingservice or application (not shown in FIG. 3). As a non-limiting example,database 318 can be a SQL database. Database 318 can store informationassociated with each slot in the test bench. As non-limiting examples,database 318 can store for each slot, test details, test history, testlogs, DUT information (e.g., DUT serial number, model name, etc),testing preferences/configuration, user interfacedetails/preferences/configuration, billing information, cloud pushinformation, MSO/customer information (media subscriber organization),OEM (original equipment manufacturer) information, slot information,user information, and any persistent data needed by the universal devicetesting system for running tests.

According to certain embodiments, universal tester 306 may include websockets 320 that are in communication (e.g., TCP/IP) with browser userinterface or operator dashboard 302 and core testing processor 324.According to certain embodiments, core testing processor 324 is incommunication with test controller 304 (e.g., TCP/IP) and incommunication (e.g., Telnet/SSH secure shell) with probes/containers(328, 330, . . . , 332, 334). Core testing processor 324 is also incommunication with configuration modules 322 (e.g., testing andenvironment configuration). Non-limiting examples of probes include Wifiprobe 328, LAN probe 330, MoCA probe 332 and WAN probe 334. There may beother types of probes including MoCA WAN probe, MoCA LAN probe and othertypes of wireless probes besides Wifi probes depending on thecharacteristics of the device being tested.

According to certain embodiments, Wifi probe 328, LAN probe 330, MoCAprobe 332 and WAN probe 334 communicate with the respective device undertest through the relevant ports on the device such as Wifi port 336, LANport 338, MoCA port 340 and WAN port 342. Core testing processor 324executes the relevant configured tests for the respective DUT. Statusand test results can be sent to the user's dashboard (using JSON formatmessages as a non-limiting example) via the web-sockets.

Non-limiting examples of devices under test (DUTs) include set topboxes, cable modems, embedded multimedia terminal adapters, and wirelessrouters including broadband wireless routers for the home or forcommercial networks.

FIG. 4 illustrates a testing architecture 400 for a cable modem/eMTAunder test, according to certain embodiments. As previously explained,multiple similar or disparate devices can be tested simultaneously andindependently of each other using the same universal tester. Thus,multiple cable modems/eMTAs can be tested simultaneously andindependently of each other using the same universal tester, along withother types of devices using the same universal tester. For purposes ofsimplicity only one cable modem/eMTA is shown in FIG. 4. FIG. 4 shows auniversal tester 404 and cable modem/eMTA (embedded multimedia terminaladapter) 402, which is the device under test for this specific case.Universal tester 404 includes a plurality of virtualization containers(probes) for communicating with corresponding interfaces of cablemodem/eMTA 402. For example, the core testing processor of the universaltester (as described herein) uses the LAN probes/containers 406 b, 408b, 410 b, 412 b to test corresponding LAN interfaces 406 a, 408 a, 410a, 412 a of cable modem/eMTA 402. Similarly, FXS (foreign exchangestation) probe/container 414b can be used to test the FXS interface 414a of cable modem/eMTA 402. WLAN (wireless LAN) probe/container 416 b canbe used to test WLAN interface 416 a of cable modem/eMTA 402. MoCA LANprobe/container 418 b can be used to test MOCA LAN interface of cablemodem/eMTA 402 via MoCA LAN bridge 418 a and splitter 420. NCS (networkbased call signaling protocol specification)/IMS (IP multimediasubsystem) probe/container 424 can be used to test DOCSIS WAN/MOCA LANinterface 430 of cable modem/eMTA 402 via CMTS (cable modem terminationsystem) 422 and splitter 420. Provision probe/container 426 can be usedto test DOCSIS WAN/MOCA LAN interface 430 of cable modem/eMTA 402 viaCMTS 422 and splitter 420. WAN probe/container 428 can be used to testDOCSIS WAN/MOCA LAN interface 430 of cable modem/eMTA 402 via CMTS 422and splitter 420. The associated core testing processor executes therelevant configured tests for the cable modem/eMTA 402. Status and testresults can be sent to the user's dashboard (using JSON format messagesas a non-limiting example) via the web-sockets.

According to certain embodiments, when executing a specific test for agiven DUT, the core testing processor loads and reads test configurationinformation (for example from an XML structure) and identifies therelevant test script that needs to be executed. Inputs that are neededfor executing the relevant test script are retrieved and supplied asinputs to the relevant test script. The following is a non-limitingsample test procedure.

Create DUT object & Environment Object

Verify Serial Number Verify Warranty Check Report Server Check DUTStaging

Checks for DUT Serial number in Database or Webservice

Get DUT Readiness Information

Checks Web-service for test readiness status of DUT in the test process

Configure Container Environment Clear Environment Temp Files ConfirmFactory Reset

Waits for operator to confirm that DUT was factory reset and booted upproperly

Check Ethernet LAN connections to DUT

Ping connections: Eth LAN 1, 2, 3, 4

Fails if any ping to these connections fail

Detect DUT

Checks connection to DUT through socket connection

Reset Password

Operator scans password which is stored temporarily for use in theremainder of test until finished

Login to GUI

Done through web-scraping

Get DUT Information and compare values

Information retrieved through web-scraping

Confirm Power Confirm all LAN Ethernet LEDs Confirm WiFi LED ConfigureWireless Network

Through telnet commands

Sets N Mode

Enables Privacy

Sets WPA (Wi-Fi Protected Access)

Removes WEP (Wired Equivalent Privacy)

Assigns WiFi Channel to DUT (channel different by slot)

[Channel 1: slots 1, 4, 7, 10, 13, 16]

[Channel 6: slots 2, 5, 8, 11, 14]

[Channel 11: slots 3, 6, 9, 12, 15]

Verifies changes through GUI

Disables WiFi once done through telnet

Check Firmware Version and Upgrade Firmware (if needed)

Firmware version varies by model

Cage Closed Confirmation Check

Asks Operator to Close Door on Cage

Connect Wireless Card

Waits on shared Resource Server (located on TC) for Resource L2 (Layer2) Lock

-   -   Lock waiting timeout: 600 sec    -   All L2 Locks are able to run in parallel but not when any L3        (Layer 3) Lock is running

Obtains Lock

Enables WiFi through telnet

Set WiFi Card

-   -   Total Retries allowed: 6 (2 sets of 3 retries)

Ping WiFi from DUT

L2 ARP Test on WiFi: must receive 10/10 ARP packets

-   -   Total Retries allowed: 6 (2 sets of 3 retries)

If either Set WiFi Card or L2 ARP Test Fail after its 3 retries, AskOperator to Check Antennas

Performs one more retry in full (set of 3 retries each for Set WiFi Cardand L2 ARP Wifi Test) after Check Antennas

Disables WiFi through telnet

Releases Lock

Wireless to LAN Ethernet Speed Test

Waits on shared Resource Server (located on TC) for Resource L3 Lock

-   -   Lock waiting timeout: 1800 sec    -   L3 Locks must be run one at a time and when no L2 Lock is        running

Obtains Lock

Enables WiFi through telnet

Connects WiFi Card

Iperf3 Speed Test, 5 seconds for UDP Speed Test, 7 seconds for TCP SpeedTest, Sending 200 Mbps Bandwidth

Bandwidth must be greater than 60 Mbps on TCP (Reverse) or 70 Mbps onUDP (Forward)

-   -   If Fail after 2 retries, ask operator to Check Antennas    -   Retries up to 2 times more if still Fail    -   Therefore, Total Retries allowed: 4 (2 sets of 2 retries)

Runs sudo iwlist wlan0 scan and returns all Wireless Signals seen

-   -   Results parsed to print all visible SSIDs and its matching        Signal level

Disables WiFi through telnet

Releases Lock

Confirm WPS LED Confirm LAN Coax LED Confirm USB 1+2 LEDs

Confirm US/DS LEDs (upstream/downstream LEDs)

Confirm Online LED Confirm Telephone LEDs L2 Test on LAN Ethernet

Arp Test from Eth LAN 1 to Eth LAN 2, 3, 4

Must receive 10/10 on all LAN connections

LAN Ethernet to LAN Ethernet Speed Test

From Eth LAN 1 to Eth LAN 2, 3, 4

Iperf3 Speed Test, 5 seconds Reverse and Forward, (e.g., Sending 1200Mbps Bandwidth)

Bandwidth must be greater than threshold (e.g., 700 Mbps) Threshold mayvary depending on the model

Total Retries allowed: 2

LAN MoCA to LAN Ethernet FTP Speed Test

From Eth LAN 1 to LAN MoCA

Iperf3 Speed Test, 5 seconds Reverse and Forward,(e.g., Sending 240 MbpsBandwidth)

Bandwidth must be greater than threshold (e.g., 60 Mbps) Thresholdvalues may vary depending on the model

Total Retries allowed: 2

LAN Ethernet to WAN DOCSIS FTP Speed Test

From Eth LAN 1 to DOCSIS WAN

Iperf3 Speed Test, 5 seconds Reverse and Forward, (e.g., Sending 1200Mbps Bandwidth)

Bandwidth must be greater than threshold (e.g., 700 Mbps) Thresholdvalues may vary depending on the model

Total Retries allowed: 2

Voice Testing

Test capability to support incoming and outgoing calls

Test capability to support 2-port, 4-port, and 8-port

Test capability to support NCS and DIP protocols

Clear Persistent Logs Final Factory Restore

According to certain embodiments, the core testing processor uses areflection and command design pattern to invoke the relevant configuredscript(s) corresponding to each DUT being tested. For example, in thecommand design pattern one or more of the following are encapsulated inan object: an object, method name, arguments. According to certainembodiments, the core testing processor uses the Python “reflection”capability to execute the relevant test scripts for a given DUT. Thecore testing processor is agnostic of the inner workings of the relevanttest scripts for a given DUT.

According to certain embodiments, lightweight software containers(virtualization containers) are used to abstract the connection ofprobes to the different DUT interfaces in order to avoid conflicts.Non-limiting examples of virtualization containers are Linux containers.As a non-limiting example, Linux container is an operating-system-levelvirtualization environment for running multiple isolated Linux systems(virtualization containers) on a single Linux control host. In otherword, lightweight virtualization containers are used to ensure isolationacross servers. By using virtualization containers, resources can beisolated, services restricted, and processes provisioned to have analmost completely private view of the operating system with their ownprocess ID space, file system structure, and network interfaces.Multiple virtualization containers share the same kernel, but eachvirtualization container can be constrained to only use a defined amountof resources such as CPU, memory and I/O. The relevant test scriptconnects to the DUT interfaces through the virtualization containers toexecute the tests. The core testing processor receives the test resultsfrom running the relevant test scripts. The core testing processor canfurther process and interpret such results and can also send the resultsto the user's browser via web sockets. According to certain embodiments,the respective core testing processors are in communication (e.g.,Telnet/SSH secure shell) with the virtualization containers (there maybe multiple virtualization containers). The virtualization containers(probes) are in communication with corresponding DUT interfaces usingTelnet/SSH/TCP/UDP/HTTP/HTTPS etc, as non-limiting examples.

According to certain embodiments, a system for testing a plurality ofdevices comprises: a universal tester; at least one test controller; aplurality of sets of testing probes; and a plurality of web sockets;wherein:

the plurality of devices includes a plurality of cable modems/eMTAdevices;

the universal tester is enabled for communication with a platformindependent user interface through the plurality of web sockets;

the plurality of sets of testing probes comprising:a plurality of LAN probes for testing corresponding LAN interfaces of acable modem/eMTA device of the plurality of cable modem/eMTA devices;at least one FXS probe for testing a corresponding FXS interface of thecable modem/eMTA device of the plurality of cable modem/eMTA devices;at least one WLAN probe for testing a corresponding WLAN interface ofthe cable modem/eMTA device of the plurality of cable modem/eMTAdevices;at least one MoCA LAN probe for testing a corresponding MoCA LANinterface of the cable modem/eMTA device of the plurality of cablemodem/eMTA devices;at least one NCS/IMS probe for testing a corresponding DOC SIS WANinterface of the cable modem/eMTA device of the plurality of cablemodem/eMTA devices;at least one provision probe for testing the corresponding DOC SIS WANinterface of the cable modem/eMTA device of the plurality of cablemodem/eMTA devices;at least one WAN probe for testing the corresponding DOCSIS WANinterface of the cable modem/eMTA device of the plurality of cablemodem/eMTA devices; and

the plurality of web sockets enable real-time bi-directional andasynchronous communication between the platform independent userinterface and the universal tester for simultaneously testing theplurality of devices under test by the universal tester.

According to certain embodiments, the system for testing a plurality ofdevices further comprises a MoCA LAN bridge.

According to certain embodiments, the system for testing a plurality ofdevices further comprises a cable modem terminal system (CMTS).

According to certain embodiments, the system for testing a plurality ofdevices further comprises a splitter.

According to certain embodiments, the real-time bi-directional andasynchronous communication of the plurality of web sockets enable a userto control the testing of the plurality of devices simultaneously butasynchronously and independently of each other using the universaltester.

According to certain embodiments, the plurality of devices installed inthe universal tester for purposes of simultaneous testing comprise a setof disparate devices.

According to certain embodiments, the plurality of devices installed inthe universal tester for purposes of simultaneous testing comprise a setof similar devices.

According to certain embodiments, the testing system is adaptable toaugmenting the test controller, the plurality of web sockets, the userinterface and the plurality of sets of testing probes to accommodatetesting of new types of devices.

In the foregoing specification, embodiments of the invention have beendescribed with reference to numerous specific details that may vary fromimplementation to implementation. The specification and drawings are,accordingly, to be regarded in an illustrative rather than a restrictivesense.

We claim:
 1. A system for testing a plurality of devices, the systemcomprising: a universal tester; at least one test controller; aplurality of sets of testing probes; a plurality of web sockets;wherein, the plurality of devices includes a plurality of cablemodem/eMTA devices; the universal tester is enabled for communicationwith a platform independent user interface through the plurality of websockets; the plurality of sets of testing probes comprising: a pluralityof LAN probes for testing corresponding LAN interfaces of a cablemodem/eMTA device of the plurality of cable modem/eMTA devices; at leastone FXS probe for testing a corresponding FXS interface of the cablemodem/eMTA device of the plurality of cable modem/eMTA devices; at leastone WLAN probe for testing a corresponding WLAN interface of the cablemodem/eMTA device of the plurality of cable modem/eMTA devices; at leastone MoCA LAN probe for testing a corresponding MoCA LAN interface of thecable modem/eMTA device of the plurality of cable modem/eMTA devices; atleast one NCS/IMS probe for testing a corresponding DOC SIS WANinterface of the cable modem/eMTA device of the plurality of cablemodem/eMTA devices; at least one provision probe for testing thecorresponding DOCSIS WAN interface of the cable modem/eMTA device of theplurality of cable modem/eMTA devices; at least one WAN probe fortesting the corresponding DOCSIS WAN interface of the cable modem/eMTAdevice of the plurality of cable modem/eMTA devices; and the pluralityof web sockets enable real-time bi-directional and asynchronouscommunication between the platform independent user interface and theuniversal tester for simultaneously testing the plurality of devices bythe universal tester.
 2. The system of claim 1, further comprises a MoCALAN bridge.
 3. The system of claim 1, further comprises a cable modemtermination system.
 4. The system of claim 1, further comprises asplitter.
 5. The system of claim 1, wherein the real-time bi-directionaland asynchronous communication of the plurality of web sockets enable auser to control the testing of the plurality of devices simultaneouslybut asynchronously and independently of each other using the universaltester.
 6. The system of claim 1, wherein the plurality of devicesinstalled in the universal tester for purposes of simultaneous testingcomprise a set of disparate devices.
 7. The system of claim 1, whereinthe plurality of devices installed in the universal tester for purposesof simultaneous testing comprise a set of similar devices.
 8. The systemof claim 1, further being adaptable to augmenting the test controller,the plurality of web sockets, the user interface and the plurality ofsets of testing probes to accommodate testing of new types of devices.